The present invention relates to automated systems for monitoring real-time events for anomalies, recurring events specified activities and the like. More specifically, the present invention relates to a system for receiving input information from a plurality of sources, processing that information according to preset, definable rules, determining if the collected data satisfies or violates the parameters of the operational rules and executing appropriate response.
The system of the present invention is divided into three tiers: data gathering, processing and operator interface. Although the three tiers are interrelated to form the system, each of the three tiers can be independently modified while maintaining the integrity of the system.
A number of data gathering units are distributed throughout the system for information collection. The collected information is then processed according to a set of precessing rules. The rules can include automated response to certain data and presentation of other data within defined parameters to one or more operators for further processing and/or response. The data gathering units can include remote units, indirectly or intermittently connected to the system, networked units, local units connected directly to the system and other data gathering units. The data collection units can communicate over wireless or land line communication channels. Communication of information can include dial up on POTS lines with transmission of information in packet data, VOA, audio, DTMF tones or other viable data transmission means.
The processing is performed on one or more servers distributed throughout the system. The servers are linked to share data from a common data base and to execute rules processing according to a common rule set. Information collected is distributed throughout the system according to specified distribution rules for effective processing and response.
The information is gathered, handled and provided to the system in a common communication data format defined by the system. The data so gathered represents events which are then processed by the system according to a set of rules. The rules are executed on a tier separate from that of the data gathering and handling. The data is first processed on a automatic level, recognizing and responding to anticipated events. If a communicated event needs specific operator intervention, the system provides information of that event to a operator for appropriate direction and response. The system also monitors for specific events which are anticipated to occur at specified times. Failure to detect such an anticipated event can result in an automated active polling to determine the nature of the failure. Continued failure to detect can result in an alert to initiate operator intervention.
The present invention uses a scalable, three-tier client/server system using a component object Model. The system can be deployed in a 32 bit Windows environment. All screen input allows for easy internationalization, either through the use of graphical labels or table/header defined variables. Scalability ideally permits the system and/or at least substantial components of the system to operate on a single Windows 95 machine for small installations, and large distributed networks for big installations. The system permits scalability simply by changing deployment strategies.
A three-tier system with COM components separates the operator interface, business rules, and data gathering/handling into separate logical components, potentially written with different applications. The MS Visual Studio is ideal for this as the contained applications are designed for development of COM components and for the use and development of ActiveX.
The true three-tier system permits use of any number of ODBC compliant databases. These includes MS FoxPro, MS Visual FoxPro, MS Access, SQL Server, Oracle, dBase and others.
Three Tiers
The three tiers are the User Interface (UI), Business Rules Processing, and Database Gathering/Storage and Handling. The present invention is described in a first embodiment below as a system for monitoring the location, movement and related activities of a population of individuals. The system is designed in such a way as to permit interchangeability of the various components at each tier. The User Interface need not be the one developed for this invention, it could be a standard browser or other front end that suits the regional or language requirements of the end user. The Database Storage tier can be any ODBC compliant database structured to contain the basic information components used by the system. This permits relatively easy regionalization and scalability. The components of each tier of the present invention are as follows:
Tier I
User Interface
The user interface includes a number of components for display of desired information to the system operators and to allow access t the database and to provide a user-friendly interface for manipulation of the data and for implementation of desired response to the data presented to the operator. The exemplary operator interface described below includes the following components:
A. Data Entry/Edit Forms
Tabbed forms with name on each page
Common navigation buttons with graphical labels
Search on multiple fields and/or grid style incremental search
Simple presentation with logical groupings and a minimum of mandatory fields
B. Incident Handling Screens
Explorer style ordering
Auto Dialer for follow-up
C. Report Generation Screens
Data driven report menus allow users to specify the unique suite of reports that they will use in their operation. In addition, the report engine permits more advanced users to develop their own reports and fit them into the system without necessitating access to the system source code.
The document creation/delivery system permits the user to generate reports to a printer or disk file. Reports sent to the disk can be viewed on the screen or transmitted to another via facsimile or e-mail.
D. Training and Testing Mode
Training mode permits new and experienced users to hone their monitoring skills without affecting any real time data. Setting a flag in the local machine""s system registry forces entry into training mode. In addition, an on line test can be administered to trainees to determine skill levels and proficiency. The test questions can be devised by administration and scored automatically by the system. Scores can be kept in an operator file and can be used to inform the skills based routing of incidents.
E. Remote Access Mode
Remote access mode is a custom interface for users dialing into the system from a remote location. This may be accomplished using any of a number of remote control applications, or ultimately on a web site via the Internet. Remote access requires password identification and presents the remote user with a subset of data (generally related to their caseload) and a subset of the functions available to local users.
Tier II
Business Rules
The business rules tier is the basic engine that determines how the system operates.
A. Communication Server Clients
Communication Server clients (ComServers) handle all communication with specific brands of Data acquisition equipment. The ComServer is designed to watch communication ports, which are assigned to a brand of equipment, and pass a normalized data xe2x80x9cslugxe2x80x9d to the database server for interpretation. ComServers provide a level of hardware abstraction for the database server by pre-processing information and passing it to the database by executing a method in the server. Typically, Data acquisition equipment calling in first identifies itself by unit number. As soon as the ComServer receives the identity block it executes the Early Warning method on the database server and passes a port ID and unit identification. The ComServer then continues to receive event information from the Data acquisition equipment. When the ComServer has received all events, it executes the Event Received method of the database server and passes the entire normalized slug. After the database server processes and stores all information, it executes the ComServer""s DataSecure method and passes any kiss-off instructions to be sent to the Data acquisition equipment.
This process of two-way communication between the ComServer and database server serves several functions. First, because the database server receives an xe2x80x9cearly warningxe2x80x9d that the ComServer has a specific unit on the line, the database server can begin to query the database and construct objects relevant to the owner of this particular unit. Second, the Data acquisition equipment is not xe2x80x9ckissed offxe2x80x9d by the ComServer until such time as it receives notification from the database server that the events have been processed and stored. Failure to get a kiss off from the ComServer will cause the Data acquisition equipment to call back and repeat the message. Finally, by using a pre-defined interface between ComServer and database server only one of the components has to be written specifically for a different brand of equipment. The ComServer handles differences between communication methods (modem, DTMF, flat file transfer, etc.) with the database server remaining essentially unchanged.
B. Database Server
The database server is the primary shared component in the middle tier. It is this component that is responsible for interpreting messages received from different ComServers into a common set of event codes, corrected (if necessary) for time zone and clock drift, and placed into the appropriate data storage tables. Similarly it processes timed out gatekeeper events and manages activation and clearing of violations upon the prompting of the violation service. The database server handles all data updates for components in the middle tier.
The database server is initiated by other middle tier or user interface components, and is never launched on its own. The database server contains several class libraries that define objects common throughout the application. These objects are described in latter detail.
While some of these objects (e.g. monitored individual, curfew, and the like) will remain fairly constant in different implementations of the system, other objects such as Slug, Last Message, and Event, may change based on the characteristics and features of the equipment being monitored.
Violation Service
The violation service determines when an incident should be presented as an alarm for follow up. All events processed by the data collection services that may be considered for processing as an alarm are placed into the violation service""s table. The violation service then checks each potential alarm against a rules table to determine how that incident is to be treated.
The rules table allows local administrators to define specific rules based on five hierarchical levels from default handling to the specific monitored individual. The violation service can determine when an incident should be xe2x80x9cactivatedxe2x80x9d for operator processing. If a xe2x80x9cclearing eventxe2x80x9d is defined and occurs within the specified time period, the violation service will clear both events. The violation service can also be directed to prepare incidents for follow-up by printing, faxing, or paging.
Gatekeeper Service
The gatekeeper service provides alarm generation on events that are the result of NOT receiving an event from specific Data acquisition equipment. Such events include OUT PAST A SET TIME, MISSING SANITY CHECKS, and FAILURE TO LEAVE AT A SET TIME. Since each of these events are based on variable schedules (curfew schedules or sanity call intervals) the host computer must handle them.
In one exemplary embodiment, gatekeeper methods required checking for these events by periodically polling the last message table for each registered Data acquisition equipment type. Each table was polled separately for each type of event, often resulting in multiple polling. This strategy has the disadvantage of requiring processor overhead, especially in installations with very large caseloads of monitored individuals.
The system of a second exemplary embodiment of the present invention avoids periodic polling. This will increase scalability by not having to dedicate a processor to this periodic polling. The gatekeeper is a communication server that monitors timer events rather than communication ports.
The gatekeeper of the present invention utilizes the services of the watchdog timer service, described below, to alert it when a gatekeeper event occurs. When the watchdog times out a gatekeeper event, it notifies the gatekeeper service when then executes a method in its associated instance of the database server to process the gatekeeper events.
The gatekeeper service is also referenced by instances of the database server that are initiated by communication server clients. The database server will execute a method in the gatekeeper service indicating the delta minutes until the next status (e.g. curfew or sanity) event for the Data acquisition equipment that it just serviced. If this time is earlier than the one that the gatekeeper has stored for this system, the gatekeeper will call the watchdog timer service and update it accordingly. If the time is later, the gatekeeper will not pass any new information to the watchdog timer service.
Watchdog Timer Service
The watchdog timer service is another important shared component in the middle tier. The sole function of the watchdog timer service is to keep a list of registered processes and the time that they are supposed to be executed. Only one timer need be set for the process at the top of the list. If this timer expires the appropriate process is notified. The watchdog timer service does not execute any methods in other COM/DCOM components other than to notify that a process has timed out. In this way, the same watchdog timer service can easily service numerous components without undue processor overhead and without getting bogged down with any one component.
There are two types of watchdog events: a watchdog monitor and a watchdog timer. They differ only in the component to be notified when the event times out. A watchdog monitor notifies any and all component objects registered with the watchdog as a monitor, while a watchdog timer notifies only the component object that set the timer.
The watchdog monitor is used to keep track of the proper operation of any unattended service. For example, each ComServer will register with the watchdog timer service with both a Ping Interval and a Line Interval (values for each are maintained in the system registry). The ping interval describes the number of minutes that the ComServer must xe2x80x9cpingxe2x80x9d the watchdog to verify that it is alive. This is often referred to as a xe2x80x9cheartbeatxe2x80x9d If the ComServer fails to respond with a xe2x80x9cheartbeatxe2x80x9d within the described interval, all registered watchdog monitors (such as a supervisor""s workstation) will be notified and corrective action (such as checking the ComServer computer) is suggested. The line interval describes the number of minutes within which a call is anticipated from the monitoring equipment. This number varies with the caseload of monitored units as is recalculated by the database server with each call received. Every time a ComServer receives an event from an Data acquisition equipment the watchdog is fed with the appropriate line interval. If the line timer is triggered, all registered watchdog monitors are notified and corrective action (such as checking the phone lines) is suggested.
The watchdog timer is used to notify other component objects that certain processes are to be initiated. Components requiring the use of the watchdog timer register with the watchdog and pass a process ID and number of minutes for the timer. When this time expires the watchdog executes the notify method in the registered component. As described above, the gatekeeper service makes extensive use of this timer.
F. Routing of Incidents
Skills based routing
Least activity routing
Same operator routing
G. Action Taken
Call to monitored individual
H. Follow-up and Notification
Notification handling rules
Notification method
Notification days and times
I. Random Contact
J. E-Mail and Facsimile Service
K. Voice Service
L. Backup and Off Site Monitoring Service
M. Security and Auditing Service
The security and auditing service is a middle tier component which in initiated when a user logs into the system. The base security object contains default permissions available to any user and can be queried whenever the user attempts to perform a restricted operation. Maintaining a separate security object allows system security to be defined and modified without altering any other components. Individual users or groups of users can be given specific permissions beyond the default.
The auditing service keeps track of changes made to the database by users. It is contained in the security object since each query to the security object which results in granting a user specific permission will also result in an entry in the audit table.
For each different type of equipment monitored, a sub-class of the base class is created with basic properties set to describe the current equipment and custom methods created, or base methods amended, to accommodate the features of the equipment. This object oriented design not only permits easy adoption of new features and equipment types into the system, but also makes maintenance and upgrades less complicated as adjustments to base classes are automatically inherited by child classes. Careful design of the methods and properties for each class allow developers to make changes at only one level in the object hierarchy.